XR Rel-19

RAN1#116

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-234080 for detailed scope of the WI.

[116-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2400922 Work Plan for Rel-19 on XR (eXtended Reality) for NR Phase 3 Nokia, Qualcomm (Rapporteurs)

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2400258 Discussion on enabling data transmissions for XR during RRM measurements vivo

· For enhancements to enable transmissions/receptions in gaps/restrictions that are caused by RRM measurements, RAN1 discusses at least the following aspects:

o Which types of gaps/restrictions that can be skipped/relaxed for transmissions/receptions;

o What transmissions/receptions that can be enabled in gaps/restrictions;

o How to enable transmission/receptions in gaps/restrictions.

· From RAN1 perspective, all types of gaps or scheduling restrictions in NR can be considered to introduce enhancements for enabling transmissions/receptions in gaps/restrictions.

· RAN1 strives for a unified solution to enable transmissions/receptions in gaps/restrictions for all involved types of gaps or scheduling restrictions.

· It is up to RAN4 to study and identify for each type of gaps or scheduling restrictions, whether/to what extent the corresponding gaps or scheduling restrictions can be skipped or relaxed, and whether/how the corresponding RRM requirements shall be adjusted accordingly.

· At least data channels and related control channels, including PDCCH/PDSCH in downlink and PUCCH/PUSCH in uplink, can be considered to trigger enabling transmissions/receptions in gaps/restrictions.

· Characteristic(s) of service data can be considered to trigger enabling transmissions/receptions in gaps/restrictions.

· The following mechanisms can be considered to enable transmissions/receptions in gaps/restrictions:

Option 1: based on gNB indication;
Option 2: based on predefined rules.

Decision: The document is noted.

R1-2400677 RRM measurement gap and scheduling restriction enhancements for TX/RX of XR traffic Ericsson

· Consider the following principals for designing the measurement gap enhancements feature:

o Network controlled cancellation

o Dynamic cancellation

o Timeline based cancellation.

· Support dynamic indication of cancellation of a MG occasion by a bit-field in a DCI format carried by PDCCH as the baseline approach.

o A bit(s) in the cancellation field is associated to a MG occasion(s) starting after the last symbol of the PDCCH carrying the DCI format and indicates whether the MG occasion(s) is cancelled.

o When a MG occasion is indicated cancelled, it should be remained cancelled.

o The first cancellation indication should satisfy a timeline with respect to the cancelled MG occasion(s).

o DCI X_1, X_2 and X_3 can be configured with the MG cancellation indication field.

· Once a MG occasion is indicated cancelled given that the corresponding timeline requirement is fulfilled:

o Scheduled UL/DL transmission(s) by a DCI and PDCCH reception in monitoring occasions within the cancelled MG are allowed.

o Note: The DCI is not necessarily configured with MG cancellation indication field.

o Configured UL/DL transmission(s) within the cancelled MG can be discussed to be allowed (preferably allow).

· For dynamic indication for cancellation of a MG, support at least the following with respect to the cancellation timeline:

o The cancellation timeline should only be satisfied for the first indication of a cancelled MG.

o The reference for the cancellation timeline is the start of the cancelled MG as the baseline.

o Discuss further how to calculate the duration of the cancellation timeline.

o Discuss further partial cancellation and corresponding timeline (i.e., reference and duration)

· Consider investigating both approaches below and potential transition between them for efficient operation.

o Approach 1 (baseline): Configured MGs are assumed enabled by default. DCI indication can cancel a MG occasion(s).

o Approach 2: Configured are assumed cancelled by default or MAC CE command. DCI indication can activate a MG occasion(s).

Decision: The document is noted.

R1-2401457 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

· Semi-persistent deactivation of measurement gap configuration/occasions using MAC-CE based indication can be signalled by the gNB. The deactivation is semi-persistent until an RRC reconfiguration or new MAC-CE is received with new deactivation pattern.

· Semi-static activation/deactivation using RRC based indication can avoid the overlapping between measurement occasions of a measurement gap configuration that collide with XR traffic. MAC-CE can be used to further deactivate specific gaps.

· A configurable priority for different semi-static channels/signals can be introduced which prioritizes certain channels/signals when colliding with measurement gaps.

· For FR2 intra-frequency L1-RSRP scheduling restrictions induced by SMTC windows, similar enhancements to those proposed for inter-frequency, intra-frequency, inter RAT measurement gap induced restrictions can be considered to prioritize data/signals transmission/reception over SMTC windows (SSB measurements).

· The UE state needs to be considered before activation/deactivation/relaxation. The UE state can include at least: UE mobility state, serving cell quality, buffer status and delay status. RAN2/RAN4 can study conditional measurement gap relaxation/activation/deactivation for XR traffic.

· The UE can indicate to the gNB with uplink signalling such as UL MAC-CE of when it will take measurement gaps, or it can be used to activate a certain measurement gap configuration.

· RAN4 to consider the RRM impact from measurement gap relaxation/activation/deactivation. This may at least include the impact of longer PSS/SSS detection, SSB index identification and measurement delays. In addition, RAN4 can consider the RRM relaxations relaxation criterion.

Decision: The document is noted.

R1-2400070 Discussion on enabling TX/RX for XR during RRM measurements Spreadtrum Communications

R1-2400129 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2400343 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2400360 Enabling TX/RX for XR during RRM measurements TCL

R1-2400423 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2400476 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2400498 Discussion on measurement gap for XR ZTE, Sanechips

R1-2400548 Discussion on enabling TX/RX for XR during RRM measurements xiaomi

R1-2400615 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2400748 Discussion on enabling TX/RX for XR during RRM measurements Samsung

R1-2400820 Discussion on Enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2400836 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2400868 Considerations on enabling UE Tx/Rx during RRM measurements Sony

R1-2400886 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI

R1-2400889 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2400921 Enabling TX/RX for XR during RRM measurements Nokia, Nokia Shanghai Bell

R1-2401028 Discussion on enabling TX/RX for XR during RRM measurements Apple

R1-2401033 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2401129 Discussion on Enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2401211 On enabling Tx/Rx for XR during RRM measurements Google Inc.

R1-2401315 Discussion on enabling TX/RX for XR during RRM measurements MediaTek Inc.

R1-2401338 Discussion on XR during RRM measurements LG Electronics

R1-2401717 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Wednesday session

Agreement

Consider at least solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements.

FFS: Other types of solutions.
Whether or not/how to account for any UE assistance information/indication in addition to other information available at the network

Agreement

From RAN1 perspective, when an occasion(s) of gaps/restrictions that are caused by RRM measurements are cancelled/skipped fully, UE is assumed to receive/transmit in the gaps/restrictions that are caused by RRM measurements as it would without any (measurement etc. related) gaps/restrictions that are caused by RRM measurements.

· FFS: Whether or not/How to support of the case where an occasion(s) of gap/restrictions that are caused by RRM measurements are cancelled/skipped partially

R1-2401718 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Friday session

Agreement

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements consider ~~at least one of~~ the following alternatives or combinations for further down-selection:

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap(s)/restriction(s) that are caused by RRM measurements.

FFS: details

Alt. 2: Semi-persistent solution ~~to deactivate/ and/or re-activate one or more of gaps/restrictions that are caused by RRM measurements and~~ to enable Tx/Rx ~~during the deactivated~~ in gaps/restrictions that are caused by RRM measurements.

FFS: details

Alt. 3: Semi-static solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

FFS: details

Alt. 4: Dynamic solution to adapt/change gap/SMTC configuration to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

FFS: details

Alt. 5: Rule-based solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements:

FFS: details

Companies are encouraged to use the EVM in TR38.835 if they are submitting simulation results.

Working Assumption

RAN1 aims to develop/identify solution(s) to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements agnostic in RAN1 normative work to types of gaps/restrictions that are caused by RRM measurements.

Note: UE features related to the developed solution(s) is a separate discussion.

RAN1#116-bis

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-240791 for detailed scope of the WI.

[116bis-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2403287 Work Plan for Rel-19 on XR Enhancements for NR Nokia, Qualcomm (Rapporteurs)

Work plan is for information.

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2402028 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2402119 Discussion on enabling TX/RX for XR during RRM measurements Spreadtrum Communications

R1-2402196 Discussion on measurement gap for XR ZTE, Sanechips

R1-2402258 Enabling TX/RX for XR during RRM measurements vivo

R1-2402268 Enabling TX/RX for XR during RRM measurements TCL

R1-2402342 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2402371 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2402482 Discussion on enabling TX/RX for XR during RRM measurements Samsung

R1-2402579 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2402593 RRM measurement gap and scheduling restriction enhancements to TX/RX XR traffic Ericsson

R1-2402654 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2402694 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2402763 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2402836 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI

R1-2402855 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2402901 Views on enabling TX/RX for XR during RRM measurements Apple

R1-2402924 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2402956 Enabling TX RX for XR during RRM measurements MediaTek

R1-2402981 On Enabling Tx/Rx for XR during RRM measurements Sony

R1-2402992 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2403129 Discussion on XR during RRM measurements LG Electronics

R1-2403149 Discussion for enabling TX/RX for XR during RRM measurements III

R1-2403210 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2403257 Discussion on enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2403286 Enabling TX/RX for XR during RRM measurements Nokia

R1-2403329 On enabling Tx Rx for XR during RRM measurements Google Inc.

R1-2403510 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Monday session

Agreement (amended as shown in red in Wednesday session)

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements consider the following alternatives or combinations for further down-selection:

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap(s)/restriction(s) that are caused by RRM measurements.

~~FFS: details~~
FFS: Alt 1-1: Explicit indication by DCI to skip a particular gap(s)/restriction(s);
FFS: Alt 1-2: Explicit indication by DCI to indicate a time window where to skip a particular gap(s)/restriction(s);
FFS: Alt 1-3: Implicit indication by DCI scheduling a transmission/reception overlapping with a gap(s)/restriction(s) to skip the gap(s)/restriction(s);
FFS: DCI format, DCI content, DCI bit-field size;
FFS: Whether indication is for one or more occasions;
FFS: How to consider time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion that is going to be skipped.

Alt. 2: Semi-persistent solution to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements.

~~FFS: details~~
FFS: Alt 2-1: gNB sends a skipping activation command, UE will skip gaps/restrictions until de-activation command is received.
FFS: Alt 2-1a: gNB sends an activation command to enable pre-configured gap(s)/restriction(s), UE will skip gap(s)/restriction(s) after de-activation command is received.
FFS: Alt 2-2: RRM measurement adaptation is applied to all MG configurations/scheduling restrictions due to all SMTC configurations, or is applied to selected MG configuration(s) and/or scheduling restrictions due to selected SMTC configuration(s) and is conducted in a time-window, and time-windows are derived from a semi-persistent ~~configuration~~ activation for their periodicity, offset and duration.
FFS: Alt 2-3: Activate/de-activate one or more of pre-configured pattern(s) via MAC-CE to indicate occasions where Tx/Rx is prioritized over gap(s)/restriction(s);
FFS: Details of activation/deactivation MAC-CE command
FFS: How to consider time offset between activation/deactivation command and start of gap(s)/restriction(s) occasion that is going to be skipped.

Alt. 3: Semi-static solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

FFS: details

Agreement

Confirm the working assumption from RAN1 #116 with updates:

· RAN1 aims to develop/identify solution(s) to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements agnostic in RAN1 normative work to types of gaps/restrictions that are caused by RRM measurements.

o It is up to RAN4 to discuss which type of gaps/restrictions caused by RRM measurements can be cancelled/skipped

o Note: UE features related to the developed solution(s) is a separate discussion

Agreement (further revised in Friday and amended as shown below)

RAN1 continues to discuss and decide whether or not to introduce new UE assistance information for solution(s) to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements. The following UE assistance information is considered for further study:

FFS: UE assistance information related to measurement occasions;
FFS: UE assistance information related to channel conditions;
FFS: UE assistance information related to traffic.
FFS: UE assistance information related to UE mobility.

Note: From specification point of view, there is no mandated gNB behavior in response to any of the UE assistance information.

RAN1 to make decision in RAN1#117 on the support of UE assistance information.

R1-2403511 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

Presented in Wednesday session

R1-2403675 Moderator summary #3 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Friday session

Agreement

RAN1 continues to discuss and decide whether or not to introduce new UE assistance information for solution(s) to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements. At least the following UE assistance information is considered for further study:

FFS: UE assistance information related to measurement occasions:

FFS: The number of needed measurement gaps/SMTC with restrictions within a time period;
FFS: The maximum number or ratio of MGs/SMTC with restrictions that can be skipped within a time period;
FFS: The number of required SSBs within a time period;
FFS: The number of consecutive RRM measurements that can be skipped;
FFS: The maximum interval between two consecutively reserved gap/restriction occasions for RRM measurements;
FFS: The patterns of gap(s)/restriction(s) where skipping is feasible or acceptable;

FFS: UE assistance information related to channel conditions:

FFS: RSRP is below/above search threshold (s-MeasureConfig);

FFS: UE assistance information related to traffic:

FFS: PSI (PDU set importance);

FFS: UE assistance information related to UE mobility:

FFS: L3 parameters related to mobility, e.g., static or not

Companies are encouraged to provide additional details (e.g. how often the UE assistance info is provided, timing, applicable scenarios, performance gains, etc) on their preferred scheme.

Note: From specification point of view, there is no mandated gNB behavior in response to any of the UE assistance information.

RAN1 to make decision, from RAN1 perspective, in RAN1#117 on the support of UE assistance information.

Agreement

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap(s)/restriction(s) that are caused by RRM measurements.

FFS: Alt 1-1: Explicit indication by DCI to skip a particular gap(s)/restriction(s);
FFS: Alt 1-2: Explicit indication by DCI to indicate a time window where to skip a particular gap(s)/restriction(s);
FFS: Alt 1-3: Implicit indication by DCI scheduling a transmission/reception overlapping with a gap(s)/restriction(s) to skip the gap(s)/restriction(s);
FFS: DCI format, DCI content, DCI bit-field size;
FFS: Whether indication is for one or more occasions;
FFS: How to consider time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion that is going to be skipped.

Alt. 2: Semi-persistent solution to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements.

FFS: Alt 2-1: gNB sends a skipping activation command, UE will skip gaps/restrictions until de-activation command is received.
FFS: Alt 2-1a: gNB sends an activation command to enable pre-configured gap(s)/restriction(s), UE will skip gap(s)/restriction(s) after de-activation command is received.
FFS: Alt 2-2: RRM measurement adaptation is applied to all MG configurations/scheduling restrictions due to all SMTC configurations, or is applied to selected MG configuration(s) and/or scheduling restrictions due to selected SMTC configuration(s) and is conducted in a time-window, and time-windows are derived from a semi-persistent ~~configuration~~ activation for their periodicity, offset and duration.
FFS: Alt 2-3: Activate/de-activate one or more of pre-configured pattern(s) via MAC-CE to indicate occasions where Tx/Rx is prioritized over gap(s)/restriction(s);
FFS: Details of activation/deactivation MAC-CE command
FFS: How to consider time offset between activation/deactivation command and start of gap(s)/restriction(s) occasion that is going to be skipped.

Alt. 3: Semi-static solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

FFS: Alt 3-1: Configure a pattern(s) via RRC to indicate occasions where to skip gaps/restrictions;

FFS: Details of pattern

FFS: Alt 3-2: Gaps/restrictions skipping is applied to all MG configurations/scheduling restrictions due to all SMTC configurations / RRM measurements, or is applied to selected MG configuration(s) and/or scheduling restrictions due to selected SMTC configuration(s) / RRM measurement(s) and is conducted in a time-window, and time-windows are derived from a semi-static configuration for their periodicity, offset and duration.
FFS: Alt 3-3: Gaps/restrictions that are caused by RRM measurements are skipped if collided with particular semi-statically pre-configured Tx/Rx occasions.
FFS: Alt. 3-4: Gaps/restrictions that are caused by RRM measurements are skipped based on semi-statically configured priority information for particular semi-statically pre-configured Tx/Rx and/or particular gaps/restrictions.

Final summary in R1-2403676.

RAN1#117

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-240791 for detailed scope of the WI.

[117-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2403951 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2404040 Discussion on enabling TX/RX for XR during RRM measurements Spreadtrum Communications

R1-2404045 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI (Late submission)

R1-2404131 Discussion on enabling TX/RX for XR during RRM measurements Samsung

R1-2404193 Discussion on enabling data transmissions for XR during RRM measurements vivo

R1-2404306 Enabling TX/RX for XR during RRM measurements Apple

R1-2404335 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2404346 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2404389 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2404470 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2404515 Enhancements to Support TX/RX During RRM Measurements Sony

R1-2404524 RRM measurement gap and scheduling restriction enhancements to TX/RX XR traffic Ericsson

R1-2404531 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2404566 Discussion on measurement gap for XR ZTE, Sanechips

R1-2404606 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2404667 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2404735 Enabling TX/RX for XR during RRM measurements TCL

R1-2404738 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2404874 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2404900 Discussion on XR during RRM measurements LG Electronics

R1-2404932 On enabling Tx/Rx for XR during RRM measurements Google Inc.

R1-2405012 Discussion on enabling TX/RX for XR during RRM measurements III

R1-2405056 Discussion on Enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2405083 Enabling TX RX for XR during RRM measurements MediaTek Inc.

R1-2405171 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2405176 Enabling TX/RX for XR during RRM measurements Nokia

R1-2405464 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Tuesday session

At least Alt1 is supported. FFS: Additional support of Alt 3.

- Nokia, InterDigital, Samsung, Ericsson, Lenovo, OPPO, MediaTek, NTT DOCOMO, Sony, ZTE, III, Panasonic, Fraunhofer

At least Alt3 is supported. FFS: Additional support of Alt 1.

- Spreadtrum, LGE, Apple, CMCC, MediaTek, Qualcomm, vivo, CATT, Huawei, Xiaomi

R1-2405465 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Wednesday session

Agreement

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements, select one or combination among only Alt1 and Alt3 from RAN1#116bis.

Conclusion

RAN1 does not further discuss new UE assistance information related to channel conditions, traffic, UE mobility.

Proposal:

In RAN1#117 select one of the following options below:

Option 1: Support UE assistance information related measurement occasion(s):

FFS: Information about the maximum number of MGs/SMTC with restrictions that can be skipped within a time period.
FFS: Information about the patterns of gap(s)/restriction(s) where skipping is feasible or acceptable.
If network indicates skipping of the measurement occasion(s) indicated by UE to be needed, the performance impact should be accounted by RAN4.
If the measurement occasion(s) indicated by UE to be needed, are not skipped, there is no RRM performance impact.
Re-using existing RRC framework for UAI.

Option 2: RAN1 does not further discuss new UE assistance information related to measurement occasions.

R1-2405665 Moderator summary #3 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Friday session

Agreement

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap(s)/restriction(s) that are caused by RRM measurements.

FFS: Alt 1-1: Explicit indication by DCI to skip a particular gap(s)/restriction(s);

Indication is included as part of scheduling DCI:

FFS: Bit-field size is one bit;
FFS: Bit-field size is >1 bit;

Note: Minimum time offset(s) between the end of [the first] received dynamic indication and start of corresponding gap(s)/restriction(s) occasion that is going to be skipped shall be introduced.

FFS: Alt 1-2: Explicit indication by DCI to indicate a time window where to skip a particular gap(s)/restriction(s);

Note: Minimum time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion in time window that is going to be skipped shall be introduced.

FFS: Alt 1-3: Implicit indication by DCI scheduling a transmission/reception overlapping with a gap(s)/restriction(s) to skip the gap(s)/restriction(s);

Note: Minimum time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion that is going to be skipped shall be introduced.

FFS: DCI format, DCI content, DCI bit-field size;
FFS: Whether indication is for one or more occasions;
FFS: How to consider time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion that is going to be skipped.

Alt. 3: Semi-static solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

FFS: Alt 3-1: Configure a pattern(s) via RRC to indicate occasions where to skip gaps/restrictions;

FFS: Details of pattern:

FFS: Pattern is based on periodicity, offset and duration;
FFS: Pattern is based on a bitmap;

FFS: whether a pattern is applied to all or subset of configured MG configurations/scheduling restrictions.

FFS: Alt 3-3: Gaps/restrictions that are caused by RRM measurements are skipped if collided with particular semi-statically pre-configured Tx/Rx occasions.
FFS: Alt. 3-4: Gaps/restrictions that are caused by RRM measurements are skipped based on semi-statically configured priority information for particular semi-statically pre-configured Tx/Rx and/or particular gaps/restrictions.

Conclusion

There is no consensus in RAN1 to support UE assistance information related to measurements occasions. The reason for this situation is lack of consensus on the need/feasibility for UAI and lack of technical understanding on issues outside of RAN1 expertise (e.g. impact of RRM measurement performance). It is up to other working groups to trigger further work in RAN1 on UE assistance information.

R1-2405667 Draft LS on UE assistance information related to measurement occasions Nokia

Agreement

RAN1 agrees to send an LS to RAN4 (CC: RAN2) to convey the following information about UE assistance information (including the conclusion on UAI):

1. Overall Description:

RAN1 discussed UE assistance information related to measurements occasions and related to channel conditions, traffic, UE mobility. The following agreement and conclusions were agreed:

Agreement

RAN1 continues to discuss and decide whether or not to introduce new UE assistance information for solution(s) to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements. At least the following UE assistance information is considered for further study:

· FFS: UE assistance information related to measurement occasions:

o FFS: The number of needed measurement gaps/SMTC with restrictions within a time period;

o FFS: The maximum number or ratio of MGs/SMTC with restrictions that can be skipped within a time period;

o FFS: The number of required SSBs within a time period;

o FFS: The number of consecutive RRM measurements that can be skipped;

o FFS: The maximum interval between two consecutively reserved gap/restriction occasions for RRM measurements;

o FFS: The patterns of gap(s)/restriction(s) where skipping is feasible or acceptable;

· FFS: UE assistance information related to channel conditions:

o FFS: RSRP is below/above search threshold (s-MeasureConfig);

· FFS: UE assistance information related to traffic:

o FFS: PSI (PDU set importance);

· FFS: UE assistance information related to UE mobility:

o FFS: L3 parameters related to mobility, e.g., static or not

Companies are encouraged to provide additional details (e.g. how often the UE assistance info is provided, timing, applicable scenarios, performance gains, etc) on their preferred scheme.

Note: From specification point of view, there is no mandated gNB behavior in response to any of the UE assistance information.

RAN1 to make decision, from RAN1 perspective, in RAN1#117 on the support of UE assistance information.

Conclusion

RAN1 does not further discuss new UE assistance information related to channel conditions, traffic, UE mobility.

Conclusion

Particularly, it was discussed whether impact on RRM performance from skipping measurement occasions may be reduced if UE sends additional information:

· Information about the maximum number of MGs/SMTC with restrictions that can be skipped within a time period.

· Information about the patterns of gap(s)/restriction(s) where skipping is feasible or acceptable.

2. Actions:

To RAN4:

ACTION: RAN1 kindly asks RAN4 to consider the above information into account and decide whether or not to introduce any UE assistance information related to measurement occasions.

Final LS is approved in R1-2405736.

Final summary in R1-2405666.

RAN1#118

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-240791 for detailed scope of the WI.

[118-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2405843 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2405886 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI

R1-2405929 Discussion on enabling TX/RX for XR during RRM measurements Spreadtrum Communications

R1-2406002 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2406065 Enabling TX/RX for XR during RRM measurements Nokia

R1-2406081 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2406201 Discussion on enabling data transmissions for XR during RRM measurements vivo

R1-2406248 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2406274 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2406304 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2406358 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2406415 Discussion on measurement gap for XR ZTE Corporation, Sanechips

R1-2406428 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2406487 Discussion on enabling TX/RX for XR during RRM measurements Sony

R1-2406506 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2406540 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2406614 Discussion on XR during RRM measurements LG Electronics

R1-2406669 Discussion on enabling TX/RX for XR during RRM measurements Samsung

R1-2406770 Enabling TX RX for XR during RRM measurements MediaTek Inc.

R1-2406787 On enabling Tx/Rx for XR during RRM measurements Google Ireland Limited

R1-2406862 Views on Enabling TX/RX for XR during RRM measurements Apple

R1-2406899 Enabling TX/RX for XR during RRM measurements TCL

R1-2406948 Discussion on Enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2407048 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2407155 Discussion on TX/RX for XR during RRM measurements CAICT

R1-2407162 RRM measurement gap and scheduling restriction enhancements to TX/RX XR traffic Ericsson

R1-2407288 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Tuesday session

Agreement

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements select one among the following options:

Option 1: Support Alt. 1-1:

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap(s)/restriction(s) that are caused by RRM measurements.

Alt 1-1: Explicit indication by DCI to skip a particular gap(s)/restriction(s);

Indication is included as part of scheduling DCI:

FFS: Bit-field size is one bit;
FFS: Bit-field size is >1 bit;

Note: Minimum time offset(s) between the end of [the first] received dynamic indication and start of corresponding gap(s)/restriction(s) occasion that is going to be skipped shall be introduced.

FFS: DCI format, DCI content, DCI bit-field size;
FFS: Whether indication is for one or more occasions;
FFS: How to consider time offset between the end of received dynamic indication and start of gap(s)/restriction(s) occasion that is going to be skipped.

Option 2: Support Alt. 3-1:

Alt. 3: Semi-static solution to enable TX/RX in gaps/restrictions that are caused by RRM measurements.

Alt 3-1: Configure a pattern(s) via RRC to indicate occasions where to skip gaps/restrictions;

FFS: Details of pattern:

FFS: Pattern is based on periodicity, offset and duration;
FFS: Pattern is based on a bitmap;

FFS: whether a pattern is applied to all or subset of configured MG configurations/scheduling restrictions.

Agreement

If Alt. 1 from RAN1#117 agreement is supported, minimum time offset(s) X between indication to skip and skipped measurement occasion is up to RAN4 to discuss and decide on particular value(s).

R1-2407289 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Thursday session

Support Alt. 1-1: InterDigital, Fraunhofer, NTT DOCOMO, Samsung, ZTE, Panasonic, Nokia, Ericsson, Sony, Lenovo, MediaTek, CAICT, Google, Meta, OPPO

Support Alt. 3-1: CATT, Qualcomm, CMCC, Huawei, vivo, Apple, Spreadtrum, Xiaomi

Working Assumption

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements select the following option:

Alt. 1: Dynamic indication to enable Tx/Rx in particular gap/restriction that are caused by RRM measurements.

Alt 1-1: Explicit indication by DCI to skip a particular gap/restriction;

Indication is included as part of scheduling DCI:

Bit-field size is one bit;

The bit in the DCI is used to indicate whether to skip the first gap/restriction occasion after a minimum time offset required between the last symbol of the PDCCH carrying the DCI format and the start of corresponding skipped gap/restriction occasion indicated by the DCI.

Send an LS to RAN4 to inform them of the above working assumption and ask them if there is any issue with it.

R1-2407512 Draft LS on gaps/restrictions that are caused by RRM measurements Nokia

Decision: The draft LS is endorsed. Final LS is approved in R1-2407561.

Final summary in R1-2407511.

RAN1#118-bis

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-241771 for detailed scope of the WI.

[118bis-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2407674 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2407720 Discussion on enabling TX/RX for XR during RRM measurements Spreadtrum Communications

R1-2407801 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI

R1-2407877 Discussion on enabling data transmissions for XR during RRM measurements vivo

R1-2407919 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2407955 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2408032 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2408077 Discussion on measurement gap for XR ZTE Corporation, Sanechips

R1-2408091 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2408153 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2408220 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2408256 Enabling TX/RX for XR during RRM measurements TCL

R1-2408259 Enabling TX/RX for XR during RRM measurements Nokia

R1-2408314 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2408424 Views on Enabling TX/RX for XR during RRM measurements Sony

R1-2408494 Discussion on TX/RX for XR during RRM measurements Apple (UK) Limited

R1-2408535 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2408583 On enabling Tx Rx for XR during RRM measurements Google Ireland Limited

R1-2408603 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2408662 Discussion on enabling TX/RX for XR during RRM measurements Samsung

R1-2408682 Discussion on XR during RRM measurements LG Electronics

R1-2408715 Enabling TX RX for XR during RRM measurements MediaTek Inc.

R1-2408801 Discussion on Enaling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2408866 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2408892 Enabling TX/RX for XR traffic during RRM measurement gaps Ericsson

R1-2409104 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Tuesday session

Agreement

At least for self-scheduling case, for explicit indication by DCI to skip a particular gap/restriction, one bit indication is included as part of DCI formats 0_1/1_1 and 0_2/1_2.

FFS: Cross carrier scheduling.
FFS: DCI formats 0_3/1_3.
Explicit indication can be configured for each DCI format individually by higher layer.

Proposal 2.1.2-v3

For explicit indication by DCI to skip a particular gap/restriction:

Bit equal to 1 indicates the corresponding gap/restriction occasion is to be “skipped”.

Option 1: Once a gap/restriction is indicated to be “skipped” by a DCI, UE does not expect the gap/restriction to be indicated as ‘not skipped’ by later DCI.

Bit equal to 0 indicates the corresponding gap/restriction occasion is to be “not skipped”. Once a gap/restriction is indicated to be “not skipped” by a DCI, the gap/restriction can be indicated to be “skipped” by later DCI.

Agreement

Clarify the note from previous agreement as follows:

Note: Minimum time offset(s) between the end of ~~[the first]~~ received dynamic indication and start of corresponding gap(s)/restriction(s) occasion that is going to be skipped shall be introduced.

R1-2409105 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Wednesday session

Proposal 2.1.2-v5-option 1

For explicit indication by a DCI to skip a particular gap/restriction:

Bit equal to 1 indicates the corresponding gap/restriction occasion is to be “skipped”.
When bit equal to 0, UE ignores the indication of this field in the DCI.

Note: Once a gap/restriction is indicated to be “skipped” by a DCI, UE assumes the gap/restriction is skipped irrespective of indication by a later DCI.

Objected by Samsung

Agreement

In case of cross carrier scheduling, for explicit indication by DCI to skip a particular gap/restriction, one bit indication included as a part of DCI formats 0_1/1_1 and 0_2/1_2 corresponds to a scheduled cell.

R1-2409106 Moderator summary #3 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Friday session

Agreement

From RAN1 perspective, the case where an occasion~~(s)~~ of gap/restrictions that is caused by RRM measurements is cancelled/skipped partially is not supported in Release 19.

Final summary in R1-2409306.

RAN1#119

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-241771 for detailed scope of the WI.

[119-R19-XR] – Margarita (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2409426 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2409526 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2409536 Enhancements to enable TX/RX for XR during RRM measurements Fraunhofer IIS, Fraunhofer HHI

R1-2409562 Discussion on measurement gap for XR ZTE Corporation, Sanechips

R1-2409613 Remaining topics on enabling TX/RX during RRM measurements for XR Samsung

R1-2409649 Discussion on enabling TXRX for XR during RRM measurements Spreadtrum, UNISOC

R1-2409697 Discussion on enabling data transmissions for XR during RRM measurements vivo

R1-2409715 Enabling TX/RX for XR during RRM measurements Nokia

R1-2409732 Enabling TX/RX for XR during RRM measurements Lenovo

R1-2409775 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2409822 Enhancements for XR Apple

R1-2409863 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2409882 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2409930 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2410096 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2410159 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2410200 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2410239 On Enabling TX/RX for XR during RRM measurements Sony

R1-2410245 Enabling TX RX for XR during RRM measurements MediaTek Inc.

R1-2410297 Discussion on XR during RRM measurements LG Electronics

R1-2410323 On enabling Tx/Rx for XR during RRM measurements Google Ireland Limited

R1-2410404 Discussion on enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2410494 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2410535 Enabling TX/RX for XR traffic during RRM measurement gaps Ericsson

R1-2410741 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Tuesday session

Agreement

For explicit indication by DCI, bit value equal to “1” indicates the corresponding gap/restriction occasion is to be “skipped”.

FFS: Interpretation of bit value equal to “0”.

Proposal 2.1.5.3a-v2:

For explicit indication by DCI, bit value equal to “0” means UE ignores the indication of this field in the DCI.

- Supported by: Qualcomm, Spreadtrum, vivo, OPPO, MediaTek, ZTE, Apple

- Strong concerns: Samsung, CATT

Proposal 2.1.5.3b-v2:

For explicit indication by DCI, bit value equal to “0” means UE behaviour for the corresponding gap/restriction occasion is as per legacy behaviour.

- Supported by: Samsung, LGE, Huawei, InterDigital, CATT, Meta

- Strong concerns: vivo, Apple, ZTE, Qualcomm

R1-2410742 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Friday session

Agreement

A component of an FG can have Option 1 as a first value and Option 2 as a second value:

Option 1: For explicit indication by DCI, bit value equal to “0” means UE ignores the indication of this field in the DCI.
Option 2: For explicit indication by DCI, bit value equal to “0” means UE behaviour for the corresponding gap/restriction occasion is as per legacy behaviour.

Note: UE indicates only one value of this component.

Agreement

For explicit indication by DCI to skip a particular gap/restriction, in addition to DCI formats 0_1/1_1 and 0_2/1_2, one bit indication can be included as a part of DCI formats 0_3/1_3.

Explicit indication can be configured for each DCI format individually by higher layer.
The skipping indication corresponds to the first gap/restriction occasion among co-scheduled cells by the DCI (Type-1C field)

Above applies only for intra-band CA cases (same SCS for cells in the set of co-scheduled cells).

RAN1#120

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-243318 for detailed scope of the WI.

Rapporteur to provide initial input on higher layer signalling under agenda item 9.10. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.

[120-R19-XR] – Jorma (Nokia)

Email discussion on Rel-19 XR Phase 3

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2501171 Initial higher layer parameters for Rel-19 XR for NR Phase3 Qualcomm, Nokia (WI rapporteurs)

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2500102 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2500134 Discussion on measurement gap for XR ZTE Corporation, Sanechips

R1-2500181 Discussion on enabling TXRX for XR during RRM measurements Spreadtrum, UNISOC

R1-2500206 Signaling control of scheduling restriction during measurement gap in support of XR services CATT

R1-2500300 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2500365 Remaining issues on enabling data transmissions for XR during RRM measurements vivo

R1-2500459 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2500486 Discussion on enabling TX/RX for XR during RRM measurements Panasonic

R1-2500528 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2500605 Discussion on enabling TX/RX for XR during RRM measurements NEC

R1-2500663 Discussion on enabling TX/RX for XR during RRM measurements Sony

R1-2500715 Discussion on enabling TX/RX for XR during RRM measurements Xiaomi

R1-2500804 Enabling TX/RX for XR during RRM measurements Apple

R1-2500865 Remaining topics on enabling TX/RX during RRM measurements for XR Samsung

R1-2500959 Discussion on XR during RRM measurements LG Electronics

R1-2501008 Enabling TX/RX for XR during RRM measurements Nokia

R1-2501172 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2501215 Discussion on Enabling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2501289 Discussion on Enabling TX/RX for XR During RRM Measurements Meta

R1-2501290 On enabling Tx/Rx for XR during RRM measurements Google Ireland Limited

R1-2501343 Enabling TX/RX for XR traffic during RRM measurement gaps Ericsson

R1-2501009 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Monday session

Agreement

Confirm the Working assumption in RAN1#118 for supporting Alt. 1-1:

Working Assumption

For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements select the following option:

· Alt. 1: Dynamic indication to enable Tx/Rx in particular gap/restriction that are caused by RRM measurements.

o Alt 1-1: Explicit indication by DCI to skip a particular gap/restriction;

§ Indication is included as part of scheduling DCI:

· Bit-field size is one bit;

o The bit in the DCI is used to indicate whether to skip the first gap/restriction occasion after a minimum time offset required between the last symbol of the PDCCH carrying the DCI format and the start of corresponding skipped gap/restriction occasion indicated by the DCI.

Conclusion

It is RAN1 understanding that if measurement gap/restriction is indicated to be skipped by explicit indication by DCI, the TX/RX is enabled on all the serving cells in the applicable range of the skipped measurement gap/restriction.

- Note: Applicable range of measurement gap/restriction is based on RAN4 specifications.

R1-2501531 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

From Wednesday session

Agreement

Agreement from RAN1#119 is updated (red part)

For explicit indication by DCI to skip a particular gap/restriction, in addition to DCI formats 0_1/1_1 and 0_2/1_2, one bit indication can be included as a part of DCI formats 0_3/1_3.

· Explicit indication can be configured for each DCI format individually by higher layer.

· The skipping indication corresponds to the first gap/restriction occasion among co-scheduled cells by the DCI (Type-1C field)

Above applies only for intra-band CA cases (same SCS for cells in the set of co-scheduled cells).

· Alt1: If skipping field is configured to DCI format 0_3/1_3, only cells that are intra-band (and have same SCS) can be co-scheduled. In other words, if co-scheduled cells could be inter-band, skipping indication field cannot be configured.

Agreement

When measurement gap/restriction is indicated to be skipped by explicit indication by DCI format 1_1/1_2 that does not schedule PDSCH and

if CIF field is present, the scheduled cell for the skipping indication is determined by CIF field.
if CIF field is not present, the scheduled cell for the skipping indication is the scheduling cell.

RAN1#121

9.10 XR (eXtended Reality) for NR Phase 3

Please refer to RP-250107 for detailed scope of the WI.

[121-R19-XR] Email discussion on Rel-19 XR – Jorma (Nokia)

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2504156 Rapporteur Inputs Nokia, Qualcomm (WI rapporteurs)

9.10.11 Enabling TX/RX for XR during RRM measurements

R1-2503288 Discussions on scheduling enhancements considering RRM measurements for XR Huawei, HiSilicon

R1-2503321 Discussion on measurement gap for XR ZTE Corporation, Sanechips

R1-2503377 Remaining issues on enabling data transmissions for XR during RRM measurements vivo

R1-2503581 Remaining topics on enabling TX/RX during RRM measurements for XR Samsung

R1-2503844 Discussion on enabling TX/RX for XR during RRM measurements CMCC

R1-2503975 Discussion on enabling TX/RX for XR during RRM measurements InterDigital, Inc.

R1-2504070 Remaining Issues on Enabling TX/RX during RRM measurements Sony

R1-2504157 Enabling TX/RX for XR during RRM measurements Nokia

R1-2504158 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

R1-2504214 Enhancements to enable TX/RX for XR during RRM measurements OPPO

R1-2504253 Discussion on XR during RRM measurements LG Electronics

R1-2504341 Discussion on RRM measurement adaptation for XR Apple

R1-2504409 Enabling Tx/Rx for XR during RRM measurements Qualcomm Incorporated

R1-2504514 Discussion on Enaling TX/RX for XR during RRM NTT DOCOMO, INC.

R1-2504608 On enabling Tx/Rx for XR during RRM measurements Google Ireland Limited

R1-2504620 Enabling TX/RX for XR traffic during RRM measurement gaps Ericsson

R1-2504158 Moderator summary #1 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

Agreement

Valid downlink slot for CSI reference resource definition is only determined based the configured measurement gap pattern and not affected by dynamic measurement gap occasion cancellation.

Conclusion

RAN1 does not discuss the measurement gap occasion cancellation for concurrent measurement gaps further unless triggered by RAN4.

Conclusion

UE does not expect different values in ‘Measurement gap cancellation’ fields in DCI formats that are associated with the same measurement gap occasion and are received in same PDCCH monitoring occasion.

R1-2504843 Moderator summary #2 - Enabling TX/RX for XR during RRM measurements Moderator (Nokia)

Agreement

Adopt following TP to draft CR of TS38.213 in Section 10.6:

10.6 Indication for cancelation of RRM measurement gaps

An ~~XYZ~~ measurement gap cancellation field in a DCI format [5, TS 38.212] provided by a PDCCH reception is associated to an earliest RRM measurement gap occasion that starts at least 3 msec or 5 msec, as determined by a reported UE capability, after the end of the PDCCH reception. The indication by the measurement gap cancellation field is applied to the associated RRM measurement gap occasion on all cells in the applicable range of the measurement gap occasion that include the one or more scheduled cells associated with the DCI format [10, TS 38.133] as described below.

A UE can be indicated by a value ‘1’ of an ~~XYZ~~ measurement gap cancellation field in a DCI format [5, TS 38.212] provided by a PDCCH reception to cancel an ~~earliest~~ associated RRM measurement gap occasion where the UE would perform RRM measurements on all cells in the applicable range of the measurement gap occasion that include the one or more scheduled cells associated with the DCI format [10, TS 38.133]. The earliest RRM measurement gap occasion is at least 3 msec or 5 msec, as determined by a reported UE capability, after the end of the PDCCH reception.

If a UE indicates “~~Value~~Option 1” for FG 64-1~~-ABC~~, the UE ignores a value ‘0’ of the ~~XYZ~~ measurement gap cancellation field in a DCI format.

If a UE indicates “~~Value~~Option 2” for FG 64-1~~-ABC~~, a value ‘0’ of the ~~XYZ~~ measurement gap cancellation field in a DCI format provided by a PDCCH reception indicates to the UE that the UE behavior for the ~~earliest~~ associated RRM measurement gap occasion ~~after the PDCCH reception where the UE would perform RRM measurements~~ ~~on cells in a same frequency band as the one or more scheduled cells associated with the DCI format~~ is as described in [10, TS 38.133]. When the UE detects more than one DCI formats that include the ~~XYZ~~measurement gap cancellation field and are associated with a same ~~earliest~~ associated RRM measurement gap occasion ~~where the UE would perform RRM measurements on cells in a same frequency band as the one or more scheduled cells associated with the more than one DCI formats~~, the UE applies the indication provided by the ~~XYZ~~measurement gap cancellation field of a last DCI format, from the more than one DCI formats~~, that is in a PDCCH reception that ends at least 3 msec or 5 msec, as determined by a reported UE capability, before the start of that earliest RRM measurement gap occasion~~.

Note: Above TP is not intended to impact future discussions related to UE features for XR.